Artikelserie Teil 1: Einführung modulare IoT-Architektur

So verschieden die diversen IoT-Anwendungsszenarien auch sind, fast immer lassen sich bestimmte Kernkomponenten unterscheiden: Device, Gateway und Datacenter beziehungsweise die Cloud. Ausgangspukt ist ein Edge-Device, an dem die Daten entstehen, die im Rahmen der IoT-Applikation erfasst werden. Ein Controllergateway – ausgestattet mit bestimmten Softwarefunktionalitäten – inspiziert die Konsistenz der eingehenden Daten, nimmt eine Aggregation vor und übermittelt die Daten an eine Applikation im Rechenzentrum oder in der Cloud. Dort erfolgt eine detaillierte Analyse und Aufbereitung der Daten für konkrete Aktionen, beispielsweise das Ändern und Anpassen von Maschinen- oder Device-Parametern.

Abb. 1: Skalierbar, zuverlässig und sicher: Das Schichtenmodell mit Geräteebene (Device Tier), Steuerungsebene (Gateway Tier) und Rechenzentrums- oder Cloud-Ebene (Data Center Tier) (Quelle: Red Hat)

Unser Beispiel zeigt die Kommunikation zwischen Edge-Device und Controllergateway. In einer Fertigungsumgebung sind Produktionsmaschinen mit Sensoren ausgestattet, die ihre Daten an ein Controllergateway übermitteln. Auf dem Gateway läuft Docker mit Red Hat JBoss Fuse als Container. Vom Gateway aus werden die Daten an OpenShift Enterprise von Red Hat weitergeleitet. Dabei handelt es sich um eine containerbasierte Anwendungsplattform auf der Grundlage von Docker und Red Hat Enterprise Linux. Die Containerapplikationen lassen sich beispielsweise auf einem Notebook erstellen, testen und anschließend im Rechenzentrum betreiben.

Zur Kommunikation zwischen Edge Device und Controller lassen sich unterschiedliche Protokolle wie DDS (Data Distribution Service), AMQP (Advanced Message Queuing Protocol) oder MQTT (Message Queue Telemetry Transport) verwenden. Hier soll MQTT zum Einsatz kommen. Die Kommunikation zwischen Controller und Rechenzentrum erfolgt via JMS (Java Message Service). In diesem Modell wird als Edge-Device ein einfacher Dummysensor implementiert, der als Temperatur- oder Drucksensor fungiert. Im einfachsten Fall startet er mit einem Initialwert. Er ändert die Daten für die Dummyapplikation mithilfe einer Zufallszahl zwischen 1 und 1 000. Wenn die Zufallszahl kleiner gleich 10 ist, wird der Datenwert um 1 reduziert. Wenn die Zufallszahl größer gleich 990 ist, wird der Datenwert um 1 erhöht. Dann werden die Daten per MQTT an den Controller gesendet. Dabei spielt es keine Rolle, ob die Daten im XML- oder im CSV-Format übertragen werden. MQTT unterstützt beide Formate.

Der Controller empfängt die Daten via MQTT, wandelt die Daten – falls sie im CSV-Format ankommen – von einem sensorspezifischen Format in XML um. Dann leitet er die Daten abhängig vom Sensortyp weiter. Er nutzt dazu Complex Event Processing, um Messages zu filtern. Ist der Wert der gleiche wie in der vorhergehenden Message, wird die Message gelöscht. Abschließend sendet er den Datensatz via JMS ins Rechenzentrum.

In der einfachsten Ausführung gibt es im Rechenzentrum Services, die Messages vom Controller empfangen, die erhaltene Daten in einer PostgreSQL-Datenbank speichern und die Daten an eine Kontrolleinheit weiterleiten, um festzustellen ob manuelle Eingriffe erforderlich sind. Dazu wird ein entsprechender Alert ausgelöst. Diese und gegebenenfalls weitere Services laufen jeweils in einem eigenen Container.

Diese Modellarchitektur bildet den Ausgangspunkt für eine realitätsnähere Erweiterung des Modells. Anstatt eines Dummysensors kommen reale, dumme Sensoren zum Einsatz, die beispielswiese mit einem Raspberry Pi als Smart-Edge-Komponente verbunden sind. Eine weitere Möglichkeit sind smarte Sensoren, die direkt auf einem Mikrokontroller wie dem ESP8266 angebracht sind. Die Smart-Edge-Komponente wird um Technologien wie Eclipse Kura [1] und Rhiot [2] erweitert. Ein Smart-Gateway, wiederum ein Raspberry Pi, übernimmt die Vorverarbeitung der Daten, die schließlich an ein Rechenzentrum weitergeleitet werden. Dort nehmen Services, die auf OpenShift von Red Hat basieren, die eigentliche Verarbeitung und Analyse der Daten vor.

Ein Schritt näher an die Realität: Edge-Device mit Mikrocontroller und Sensor

Der ESP8266 ist ein kostengünstiger WLAN-Baustein, der in unterschiedlichen Varianten erhältlich ist, beispielsweise mit einer unterschiedlichen Anzahl an GPIOs (General Purpose Input/Output)-Pins. Es gibt mehrere Möglichkeiten, um den ES8266 zu programmieren oder die Firmware zu flashen. Für diesen Zweck eignet sich etwa die Arduino-IDE [3]. Eine gute Einführung zur Einrichtung einer IoT-Entwicklungsumgebung gibt es unter www.iot-playground.com. Der Sensor DHT22 misst die Temperatur und die Luftfeuchtigkeit in der Umgebung. Wie die Daten vom DHT22 gelesen werden zeigt Listing 1.

Um die Kombination aus ESP8266 und DHT22 als Edge-Device einsetzen zu können, existieren verschiedene Optionen. Auf dem Markt sind beispielsweise Entwicklerboards erhältlich, die sich direkt an einen PC anschließen lassen. Andere verbinden den ESP8266 über einen USB-2-TTl-Adapter und eine Steckkarte. Das hier vorgestellte Szenario folgt einem unter Arduino ESP [5] beschriebenen Setup.

Der Sensor stellt die Verbindung zu einem vorhandenen WLAN her (Listing 2). Er misst im Sekundentakt die Temperatur sowie die Luftfeuchtigkeit und schickt die Temperaturwerte in einem MQTT-Topic namens iotdemo/temperature/<device_id> an das Gateway (Listing 3 und 4). deviceType repräsentiert dabei das, was gemessen wird (z. B. Temperatur, Luftfeuchtigkeit) und deviceID eine eindeutige ID des Sensors. Und damit steht unser smarter Sensor.

Der zweite Teil des Beitrags befasst sich im Detail mit dem Raspberry-Pi-basierten Smart-Gateway und dessen inhaltlicher Logik.

Links & Literatur

[1] Eclipse Kura: https://wiki.eclipse.org/Kura
[2] Rhiot: https://www.gitbook.com/book/rhiot/rhiotdocumentation/details
[3] Arduino-IDE: https://www.arduino.cc/en/Main/Software
[4] Einführung in IoT-Entwicklungsumgebung: http://iot-playground.com
[5] Set-up: http://www.arduinesp.com